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Abstract 

An algorithm for continuously computing safe maximum relative velocities for two 
bodies joined by a manipulator is discussed. The maximum velocities are such that if the 
brakes are applied at that instant, the ensuing travel between the bodies will be less than 
or equal to a predetermined amount. This paper deals with an improvement in the way 
this limit is computed for space manipulators. The new method is explained, test cases 
are posed, and the results of these tests are displayed and discussed. 

I. Introduction 

A. What is a pavload rate limit alg orithm? 

The rate limit for a payload is, in effect, a "speed limit" for the rates the payload is 
allowed to achieve relative to the manipulating body. Observance of this rate limit 
ensures that the payload's relative motion can be arrested at any time during a maneuver 
(e.g., in an emergency such as a joint runaway detection) without exceeding a specified 
amount of overtravel after application of the brakes. Any method employed to compute 
these rates must consider items like brake torque capability of the manipulator and 
masses of the payload and manipulator base. 

The Remote Manipulator System (RMS) on NASA's Space Shuttle currently 
utilizes a rate limit algorithm to compute a single (constant) rate limit for each payload to 
be manipulated during a mission, and these rates are loaded into the on-board computer 
system prior to the mission. These rates are designed to ensure a stopping distance of 
the end-effector (not the payload c.g.) in two feet or less when the arm is in an out- 
stretched position (worst-case). 


B. What is wrong with the current rate limit algorithm? 

The algorithms developed to determine the rate limit for a payload to be carried by 
the RMS were developed by SPAR Aerospace, Inc. in August 1979 with revisions in 
February 1983 [Ref. 1,2]. These algorithms were designed for the original payload mass 
range of up to 65,000 lbm. (vs. Shuttle mass of 220,000 lbm), and also assumed a worst- 
case RMS configuration (fully extended). While these algorithms have performed well for 
the range of payloads seen so far, they produce rate limits approaching zero for payloads 
whose masses exceed 100,000 lbm. They also produce only one limit, based on the worst- 
case configuration, when in fact the RMS's ability to arrest relative motion is dependent 
on arm configuration and the direction of the motion to be arrested. This means the rate 
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limits calculated are lower than necessary (conservative), so the payload is always 
manipulated at rates lower than actually required for safety. 


C. Why should we care? 

The RMS manipulator is basically a dexterous crane that has to perform large- 
excursion travel in many of its tasks. If used, the low rate limits that the current 
algorithm produces for the massive payloads will cause increases in the time required to 
perform the job because the arm will move much slower than is necessary for safety. The 
low rate limits also push all the commands down into the low end of the command scale. 
This lessens the number of bit-states which can represent the command, thereby 
decreasing resolution and accuracy of the command actually sent to the joint servos. 

The current algorithm must be changed to consider payloads more massive than 
65000 lbm., and must consider the fact that the Shuttle also moves during the braking 
process. Since the algorithm will require at least an update to handle the larger payloads, 
this is a good time to look into deriving a better method. This method should be 
dependent on the arm configuration and commanded velocity. 

Some analysis on improving the algorithm has been done before, but the algorithm 
arising from that analysis was still a single limit for a payload [Ref. 3]. That method did, 
however, take into account the fact that the Shuttle moves during manipulation, and was 
the basis of this current effort. 


II. Proposed New Pavload Rate Limi t Algorithm 


A. What should it do? 

Any new method should include better models of system dynamics, and yet be 
computationally simple. Simplicity will enable calculation of the limit in real-time as a 
function of the current arm configuration and the requested direction of motion. The new 
method should also consider relative rotational motion, and allow a maximum rotation 
angle as an additional criterion. 

The end goal of this algorithm should be to produce a rate limit which is higher than 
the currently-used conservative value yet is still safe. 


B. How can it be done? 

1. System Dynamics 

By considering the system dynamics of the payload and the Shuttle over the 
process of: 

Phase 1. beginning with relative rates (possibly zero) 
between Shutde and payload. 

Phase 2. accelerating the payload and Shuttle to some new 
commanded relative rate, and finally 


264 


i 



Phase 3. applying the brakes until all relative rates have 
been arrested, 

one can see that, since we assume no external forces, system momenta is conserved 
throughout this process. The dynamics from the time of brake actuation to arrest of 
relative motion (Phase 3) can be viewed as an inelastic collision, in which both bodies 
have initial relative motion, collide and stick together, and then proceed on as one body. 

Realizing that the final system velocity Vf is constant, we can define a reference 
frame F, translating at velocity Vf, The final rotational rates of the system are expected 
to be very small (less than 0.2 degrees per second) This means we can allow the frame F 
to rotate with the system at its final rotational velocity and still consider it inertial 
(pseudo-inertial). In this frame, an observer would see that each body would have an 
initial velocity, but would come to rest at impact. The relative velocities between these 
two bodies would be the commanded velocity. The momentum equation can be written for 
each body in this pseudo-inertial frame: 

miVi + | F(t) dt = 0 and ™z)lz ' | £<t) dt = 0 

SO 

- • if fc 

which says that the initial velocities of the two bodies in this frame will always be 
opposed and parallel. Because the common direction of these velocities is also the 
direction of the relative velocity, and we assume the force between the bodies to be 
opposed to the relative velocity so everything falls on this line, leaving us a scalar 
equation. 

Writing the equation of linear momentum for the system in frame F, we get the 
following equations, which we can treat as scalar since all vectors are parallel. 

For the entire system (no external impulse) : 

miVi + ITI2V2 = 0 

For bodies 1 and 2 individually (external impulse from arm) : 


mi Vi + j F(t) dt = 0 m 2 V 2 - J F(t) dt = 0 

where (V 2 ' Vi) is the commanded velocity. 

2. Estimation of Impulse 

If we had some idea about what kind of impulse we could expect to see, we could 
extrapolate what the travel motion of the system would be. The impulse does not have to 
be exactly known, but the estimate must be less than the actual impulse, and still 
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produce a rate faster than the old value. A way to estimate the impulse is to estimate the 
initial force or torque, and then estimate the manner in which it approaches zero. 


Any force applied by the RMS to the bodies it connects will result from brake 
slippage and storage of strain energy in the booms and gearboxes. Since only brake 
slippage is non-conservative, this mechanism alone will be considered. The potential 
brake torque at each joint is assumed to be known. In this case, the initial resistive force 
encountered by the bodies can be estimated. By assuming all joints required to contribute 
to the commanded motion will slip if the brakes are applied, a vector of brake torques can 
be created which is an estimate of the torques which would be seen at each joint: 



hi * sign(Y!)\ 


\t 6 * sign (ye)/ 

where signQ is -1 if the commanded joint rate is negative, zero if zero, and +1 if positive. 


Here we assume that the inverse of the Jacobian matrix relating end-effector 
states to joint states is known or easily obtained. Multiplication of the transposed 
inverse of the Jacobian by the brake torque vector just constructed results in the static 
moments and forces at the end-effector to counteract those brake torques. 

( I ) - [j] T (S) 


These loads at the end-effector will not generally be parallel to their counterpart 
velocities. The components of these loads in the direction of those velocities are an 
estimate of initial loads the payload and shuttle will encounter, while the components 
normal to those velocities are assumed to arise from the errors in the assumed joint 
torque vector. 

Tmax = X ' 

Fmax = X • V c 

where 

^ /N 

Vc. co c are the unit vectors of the commanded velocities, and Tmax. 
Fmax are the available torque and force in those directions (scalar). These loads are the 
estimates of the actual initial loads seen upon applying the manipulator brakes. 

So far this method predicts the initial loads seen at the beginning of the braking, 
but its behavior of these loads over time is unknown. Since we are only having to 
compute a conservative limit, we only need assume a conservative load profile, i.e. the 
assumed profile's integral must always be less than or equal to the actual impulse. 
Nominally, loads due to brake slippage could be thought of as constant over time, but 
simulation has shown that these loads tend to drop off over the braking maneuver. To be 
conservative, we assume a profile in which the loads begin at the predicted value (F ma x, 
Tmax). but then linearly ramp down to zero over the time of the maneuver. 
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Once we know or assume a force-time profile (impulse), we can determine the 
distance travelled over that time and make sure all distances travelled are less than 2 feet 
(or some other criterion). 

To do this, we must look at the equations of motion of these bodies along the line 
of action in frame F: 

F(t) = A - Bt ( 0 < t < tend ) 

where F(t) is the force exerted on each body, 

tend is the time at which motion stops 

A is the maximum force Fmax computed above 

B is the slope at which F(t) ramps down, 
i.e., FmaxAend 

so the acceleration of each mass is 
a(t) = (A - Bt)/m 
and the velocity of each mass is 


v(t) = 


a ( t ) dt + V(t-O) 


= (At - Bt2/2)/m ( 0 < t < t en d ) 
and the distance travelled by each mass is 


x(t) = 


V(t) dt + X(t-O) 


= (At 2 /2 - Bt3/6)/m ( 0 < t < t en d ) 

We can also see that since 

xi(t=t en d) + x2(t=t en d) < 2 feet 
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we can back out a relationship between the F ma x and the amount of time required to 
arrest the motion, tend. 

2 feet = (Atend 2 / 2 - Btend 3 /6)(l/mi + l/m2) 

or, substituting for A = F max , and B = F max /t en d> we get 

tend = V” [3*d*mi*m2/((mi+m2)*F max )] 

where d is the stopping distance allowed, which is 2 feet for the RMS. 

Once we know the amount of time required to arrest the motion, we can use the 
momentum equations for each body: 

mi Vi + impulse = 0, m2V2 + impulse = 0, 

and since the impulse is the area under the assumed force-time curve, 

impulse = 1/2 F max Tend 

and the final allowable command velocity is V2 + Vi, 

Vmax = (Fmax * tend/2) * [ 1/mi + l/m2] 
b. Rotational Velocity 

The computation of the maximum safe rotational velocity closely parallels that of 
the translational. An assumption of the torque-time profile (linearly approaching zero) is 
made, and the equation of angular momentum is written for the system about the end- 
effector tip. This requires that all body inertias be computed about that point. 

The assumed torque-time profile is 

T(t) = A-Bt ( 0 < t < tend ) 

where A is T max ( initial torque) 

B is the slope at which it ramps down (T ma xAend)- 

For each body, 

T(t) = la 

where 

I is the scalar moment of inertia at the end-effector about the rotation 

axis, and 

a is the rotational acceleration. 

Solving for a, Ate, and A0 
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and 


a = I'^A-Bt] 


Acg = l' l [At -Bt2/2] 


and 

A0 =I 1 [At2/2- Bt3/6] 

As before, we set the travel constraint 

10 degrees = A0 1 + A02 ( at t=tend ) 
or 

0max = 10 degrees = (^l 1 + ^2 ) [Tmax tend^/3] 
which yields the expression for tend 

tend = V” '«e max /57.3 * Ill2*3)/((Ii + I 2)*T max )) 

which yields the expression of commanded velocity 

(ftnax = (Tmax tend/2) * [^1 + ^2 ] 
much as the translational equation. 

This V m ax and (Umax are the magnitudes of the allowable velocity in the 
commanded direction. This command is what would be sent on to the robot controller, 1 
the operator desired to go the maximum safe speed. 

4. A pplication of Limit to Command 

Obviously, an operator would not want to go the maximum safe speed in all 
situations, so what to do with the knowledge of this instantaneous speed limit raises 
several possibilities. One way to apply the limit would be to use some constant 
conservative limits under normal operation, and use the maximum limits whenever a hand 
controller has been fully deflected in some axis. Another method would be to use the 
maximum limit as the upper end of the hand-controller's range, i.e. if the hand-controller is 
deflected 50% in some direction, then the commanded velocity would be 50% of the 
maximum safe velocity. This latter appears to be possibly unwieldy for the operator, 
since a constant deflection of the controller would produce varying velocity commands as 
the arm's configuration changes. Either of these methods could be implemented as an 
operator-requested mode. 

III. Tests. Results and Co nclusions 

A. How can we evaluate this n ew algorithm? 

In order to evaluate the performance of the algorithm, dynamic simulation of the 
Shuttle/RMS/Payload system was required. This was done with a dynamic batch 
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simulation program developed at the Johnson Space Center which uses an extensive 
model of the Shuttle and the RMS. This program (called MIRRORS, for Model for 
Integrated Robotics Research and Operational Requirements Synthesis) is a spin-off of 
the PDRSS (Payload Deployment and Retrieval System Simulator, which is a spin-off of 
the SVDS (Space Vehicle Dynamic Simulator), which was written during the Apollo 
Program. The program has been checked against actual flight data from Shuttle/RMS 
missions as well as other simulators, and is used routinely for RMS maneuver simulation. 

The underlying idea behind the evaluation was to get a prediction of safe velocity 
from the algorithm and then start the simulation with those velocities and the brakes on, 
watching the ensuing travel. This was done while varying command direction, payload 
mass and arm configuration. The commands given were all single-axis commands: 

X - translate in positive Orbiter X-axis (toward nose) 

Y - translate in positive Y-axis (toward starboard wing) 

Z - translate in positive Z-axis (down toward bay) 

R - rotate in positive direction about X-axis (roll) 

P - rotate in positive direction about Y-axis (pitch) 

Y - rotate in positive direction about Z-axis (yaw). 


The algorithm was coded into the flight software module of the MIRRORS 
program. Tests were run in the following manner for commands in each rotational and 
translational axis: 

1. For given command direction, determine from the algorithm the maximum safe 

speed. 

2. Initialize simulation with payload moving at that speed in the commanded 
direction, and with the brakes just applied. 

3. Let simulation run until motion arrested, compare amount of travel with specified 
maximum (2 feet or 10 degrees in all cases). 

The test runs were conducted for three different payloads, all 15 foot diameter 
homogeneous cylinders, grappled on the side at the midpoint, having masses of 32000, 
100000, and 250000 lbm. The test also used two different initial arm configurations for a 
total of 6 * 3 * 2 = 36 test runs. 

To evaluate the amount of travel, the code was altered to compute the Euclidean 
distance from the current position to the point where the brakes were applied. For tlje 
rotational cases, the angular displacement about the relative rotational eigen-axis 
(component of the quaternion relating payload attitude relative to the Orbiter) was 
computed. These are included in the test results below. 

B. What were the test results? 

The test results for all 36 runs were in general agreement with the desired end 
goals, in that 33 of 36 runs resulted in payloads travelling 2 feet/10 degrees or less while 
at speeds faster than the old method would allow. Three runs, however, did result in up 
to 2.3 feet of travel, all in the Z direction. The results of all the runs are tabled below, for 
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each arm configuration (joint angles from shoulder yaw to wrist roll shown in 
parentheses). The three runs that exceeded the travel limits are also noted. 

The format for the data for each run (three numbers) is as follows: 

[1] rate limit as predicted by old method (feet/sec or deg/sec) 

[2] rate limit as predicted by new method 

[3] stopping distance or angle for new rate (feet or degrees) 

ARM CONFIGURATION #1 ( -90,90,-71,0,0,0 ): 


Command Directions 

X Y Z R P Y 

feet /sec and feet degrees/sec and degrees 


ray- 

load 

32K 

0.153 

0.250 

0.990 

0.153 

0.252 

0.354 

0.153 

0.324 

2.365* 

0.498 

1.372 

2.027 

0.498 

0.687 

3.417 

0.498 

0.718 

3.177 


0.100 

0.100 

0.100 

0.284 

0.284 

0.284 

100K 

0.160 

0.161 

0.207 

0.779 

0.400 

0.411 


0.749 

0.223 

2.362* 

1.907 

3.497 

3.000 


0.071 

0.071 

0.071 

0.180 

0.180 

0.180 

250K 

0.123 

0.124 

0.159 

0.497 

0.269 

0.267 


0.624 

0.228 

2.225* 

2.037 

3.690 

2.770 


old rate limit 
new rate limit 
stopping distance 
or angle 


Exceeded 2' criterion 


ARM CONFIGURATION #2 ( -48,118,-118,-26,-39,3 ): 


Command Directions 

X Y Z R P Y 

feet /sec and feet degrees/sec and degrees 


Pay- 

Load 



0.153 

0.153 

0.153 

0.498 

0.498 

0.498 


32K 

0.361 

0.349 

0.287 

0.195 

0.502 

0.935 


1.445 

1.364 

0.975 

0.101 

0.229 

0.445 


0.100 

0.100 

0.100 

0.284 

0.284 

0.284 

100K 

0.231 

0.223 

0.183 

0.112 

0.291 

0.542 


1.283 

1.215 

0.874 

0.101 

0.229 

0.435 


0.071 

0.071 

0.071 

0.180 

0.180 

0.180 

250K 

0.177 

0.171 

0.141 

0.730 

0.193 

0.361 


1.161 

1.101 

0.831 

1.206 

0.232 

0.444 
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The amount of additional computer time required to compute this rate limit was 
negligible for the simulation, which is already numerically intensive. This is not an 
indication of its impact on some other manipulator, although the scheme doesn't require 
much numerical work provided the inverse of the Jacobian matrix is available. 


C. Anv conclusions? 

Since the tests did produce three runs which exceeded the 2 feet limit, one 
conclusion is that further work is needed in better estimating the impulse imparted 
between the bodies. However enough runs (33 out of 36, or 92%) not only stopped well 
within the limit, but at speeds faster than the present method would allow, which 
indicates the potential worth of this form of electronic safety monitoring. The conclusion of 
the study conducted to date is that further investigation is warranted to increase accuracy 
of the impulse estimation. If this can be improved and remain numerically simple, the 
algorithm will be a useful tool in speeding-up tasks for space robots. 
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